For Task Tracker to function on a mass scale, it needs to have definable tasks that run on a per-server basis. This means the information for each server needs to be stored somewhere.

This section goes through each attempt of solving this issue.

DS: Iteration #1

---

The first iteration used a global database to store server data. I worked on this concept for some time before realizing I obviously could not store a database of possibly private information that I could access.

DS: Iteration #2

---

The second and last iteration uses a mix of local data and a global list to define the server data (tasks).

As an example, to register the bot, you would first invite it via a special link. Once in the server, run the register command (as will be documented) to register your server.

This command will write the default settings to a private (excluding server admins/owner) channel and add the ID to the global list, after that completes, a help message to get started with the SetupWizard is displayed to the user.


- Global List | JSON

The global list is a JSON file hosted on a private discord server.
This file contains no personal information, only a dictionary of channel IDs with a value of 0. It is created like this so no duplicates can be made.

Each channel ID references a channel in which a local settings file exists.

When the code to execute tasks runs, it iterates through this dictionary and adds a new async function for each channel.
The async function downloads the local settings and parses them; if any tasks are set to run at

DateTime.Now

they are executed accordingly.


- Local Settings | JSON

The local settings file is also a JSON file, but it is hosted in the server (local to that server).
This file contains two primary indexes, "vars" and "tasks" and one property "timezone".

The Vars dictionary holds user-defined variables that can be used in the task message.

Tasks define what happens at any point in time. Only a basic notification system is implemented as of now, but over time it could expand to support a broader range of things.

All of this data will be formatted by the SetupWizard where you can add/remove tasks and variables.

DS: Iteration #3

---

In the original server settings, tasks were defined as a

Dictionary<string, Dictionary<string, dynamic>>

, the first

string

being the DateTime.

This needs to be removed because all dictionary keys must be unique, having only one task per time, we are restricted from running multiple tasks at any given time.
The new solution is to add the time as a property inside the dictionary and give a unique hex-based id to each task. | Download updated JSON data.

DS: Iteration #4

---

Having the tasks in a dictionary is reduntant outside of the Setup Wizard (where the ID is used for saving), it is therefore removed and made into a list in the server-side data. | Download updated JSON data.

Efficiently tracking tasks is essential for this program. Because it is done so often (every minute), it needs to execute quickly to be finished before the minute is up. This will be done with asyncio, a python package for thread management.

The following section goes through each attempt of solving this issue.

TH: Iteration #1

---

The first iteration in this section proposes a system where each server is handled on its own thread, so they are all done at the same time.

Python Code >

The

handle_server

function parses the local settings and iterates the tasks with a similar method as defined above.

Python Code >

For the end-user to add and remove tasks, they need a user-friendly interface to do that. Most Discord bots have their own website for adding it to your server and configuring it.
Some popular examples would be YAGPDB (yagpdb.xyz) and MEE6 (mee6.xyz).

The primary issue with this approach is money, it cost a bit annually to host a website, which is one of the reasons I chose not to do this. (I did later figure out how to host a website for free using GitHub Pages. I.e., this website)

The second reason for not creating a web-based configuration system is merely due to my lack of knowledge in JavaScript or another web-based programming language. So I instead settled on making a C# compiled Desktop application.

Note: This section does not go through each iteration like before, but summarizes the whole process and then outlines some changes made throughout development at the end.

SC: Summary

---

My original plan was to handle this with bot commands, but I decided to go a step further and make a full application to handle it.
After deciding on creating an application, I started with just a WPF template I developed last year and finalized in early April of this year.



The WPF template, built with C# 10 and DotNET 6.0, has built-in support for GitHub/Discord error reporting, customizable dark and light themes, and many other features useful for development. I ended up saving a lot of time by using this as a base for my application.

I then made a basic user interface, aiming to create a visual representation of the local settings data. And before long I had three views set up to display their corresponding data in the local settings.

• timezone | The Timezone setting is defined in the server settings panel in a TextBox.


• tasks | The servers Tasks are held in a BindableCollection<TaskViewModel> bound to a DataGrid element.


• vars | The servers Vars (Variables) are inside a BindableCollection<VarViewModel> and bound to the second DataGrid element.

---

The next hurdle was synchronizing the user's server. First, a key (channel id) is kept locally in the application settings; with this, the actual synchronizing can be done with the unofficial Discord API Discord.NET and a bit of logic to connect the bot and upload the serialized data. This solution is not ideal, as it allows users to mess it up easily by not adding the key, or changing it in any way. I intend to find a better solution to this in the future.

Finally, with all the main features implemented, I cleaned up a few things here and there, doing a few basic tests along the way, and built a release version that the Python side could reference.

SC: Changes

---

In this section, a list of changes is documented with an idea, issue, or just an original implementation ( i ) and a solution to the idea ( a ).

i. Use the DataGrid to edit the task properties. a. This was found to be very inefficient and was scrapped very early in development.

i. Allowing users to add new items using the DataGrid default implementation. a. This prevents the program from stopping the user if required data fields are missing, this behavior was removed.

i. When synchronizing, the thread continued before the bot had connected, meaning it was never known when the server had fully synchronized. a. This is fixed with an infinite loop running on a side thread to await synchronizing, when it has fully synchronized, the loop is broken.